Method and system for controlling software updates on a network connected device

ABSTRACT

A method at a computing device acting as a switchboard between an electronic device and a device to be updated, the method including receiving, at the computing device, a connection request from the electronic device, the connection request including an identifier for the device to be updated; receiving, at the computing device, a connection request from the device to be updated; associating, at the computing device, the connection request from the electronic device and the connection request from the device to be updated; forwarding, at the computing device, a message from the device to be updated to the electronic device that update conditions have been met; forwarding, at the computing device, a message from the electronic device to the device to be updated to start an update process; and forwarding, at the computing device, update status information from the device to be updated to the electronic device.

FIELD OF THE DISCLOSURE

The present disclosure relates to over-the-air updates for networkconnected devices, and in particular relates to the over-the-air updatesfor network connected devices having no feedback mechanism.

BACKGROUND

Network connected devices often contain software that occasionally needsto be updated. For example, in vehicles, an electronic control unit(ECU) controls a system or subsystem of the vehicle, and mayoccasionally need firmware or software updates.

However, in many cases, such network connected devices may not have agraphical user interface to provide for the initiation of an update, noris there any mechanism to provide feedback as to the status of anupdate.

Further, in many cases, it is undesirable to push an update to suchnetwork connected device at a random time. For example, it would bedangerous to push an update to a braking system in a vehicle while thevehicle is in operation. Even if the vehicle is stopped or if the engineis off, in some cases it may not be an appropriate time to make anupdate. For example, a vehicle may be at a weighing station or fuelingstation, and the pushing of the update may prevent the vehicle fromleaving such station for an extended period of time, delaying othervehicles from being serviced at such station.

BRIEF DESCRIPTION OF THE DRAWINGS

The present disclosure will be better understood with reference to thedrawings, in which:

FIG. 1 is a block diagram showing an example architecture for a systemin accordance with the embodiments of the present disclosure;

FIG. 2 is a data flow diagram showing the updating of a device using aswitchboard and an electronic device;

FIG. 3 is a block diagram showing data structures for associating anelectronic device with a device to be updated;

FIG. 4 is a block diagram of an example computing device capable ofbeing used with the embodiments of the present disclosure; and

FIG. 5 is a block diagram of an example mobile device capable of beingused with the embodiments of the present disclosure.

DETAILED DESCRIPTION OF THE DRAWINGS

The present disclosure provides a method at a computing device acting asa switchboard between an electronic device and a device to be updated,the method comprising: receiving, at the computing device, a connectionrequest from the electronic device, the connection request including anidentifier for the device to be updated; receiving, at the computingdevice, a connection request from the device to be updated; associating,at the computing device, the connection request from the electronicdevice and the connection request from the device to be updated;forwarding, at the computing device, a message from the device to beupdated to the electronic device that update conditions have been met;forwarding, at the computing device, a message from the electronicdevice to the device to be updated to start an update process; andforwarding, at the computing device, update status information from thedevice to be updated to the electronic device.

The present disclosure further provides a computing device configured toact as a switchboard between an electronic device and a device to beupdated, the computing device comprising: a processor; and acommunications subsystem, wherein the computing device is configured to:receive a connection request from the electronic device, the connectionrequest including an identifier for the device to be updated; receive aconnection request from the device to be updated; associate theconnection request from the electronic device and the connection requestfrom the device to be updated; forward a message from the device to beupdated to the electronic device that update conditions have been met;forward a message from the electronic device to the device to be updatedto start an update process; and forward update status information fromthe device to be updated to the electronic device.

The present disclosure further provides a computer readable medium forstoring instruction code, which when executed by a processor of acomputing device configured to act as a switchboard between anelectronic device and a device to be updated, cause the computing deviceto: receive a connection request from the electronic device, theconnection request including an identifier for the device to be updated;receive a connection request from the device to be updated; associatethe connection request from the electronic device and the connectionrequest from the device to be updated; forward a message from the deviceto be updated to the electronic device that update conditions have beenmet; forward a message from the electronic device to the device to beupdated to start an update process; and forward update statusinformation from the device to be updated to the electronic device.

Therefore, in accordance with the embodiments of present disclosure,methods and systems are provided for network connected devices that haveno graphical user interfaces, but which have network interfaces, to haveupdates initiated and monitored through another electronic device. Anetwork connected device, as used herein, may be any stationary ormobile computing device. For example, the device may be any deviceaffixed to or part of shipping containers, truck trailers, or truckcabins in one embodiment. In other embodiments, the device may beaffixed to or part or any vehicle, including motor vehicles (e.g.automobiles, cars, trucks, buses, motorcycles, etc.), aircraft (e.g.airplanes, unmanned aerial vehicles, unmanned aircraft systems, drones,helicopters, etc.), spacecraft (e.g. space planes, space shuttles, spacecapsules, space stations, satellites etc.), watercraft (e.g. ships,boats, hovercraft, submarines etc.), rail vehicles (e.g. trains andtrams, etc.) and other types of vehicles including any combination ofthe foregoing, whether currently existing or after arising, amongothers.

In other cases, the network connected device may be a device such as anInternet of things (IOT) device, endpoints, home automation devices,medical equipment in hospital or home environments, inventory trackingdevices, environmental monitoring devices, energy management devices,infrastructure management devices, vehicles or devices for vehicles,fixed electronic devices, among others.

The network connected device may connect, in some cases, to a networkthrough another device. For example, the network connected device may bean ECU in a vehicle that communicates using a gateway in the vehicle toconnect to, for example, a cellular network. Other options for suchdevices are possible.

Further the electronic device having a user interface may be anycomputing device, including a mobile device such as a cellulartelephone, smartphone, internet appliance, laptop, desktop computer,smart watch, wearable, or other similar device.

While the embodiments of the present disclosure are provided below withregard to vehicle systems, the present disclosure is not limited tovehicle systems and any device having a network connection can be usedwith the embodiments of the present disclosure.

In the case of vehicles, the specific timing of an update cannotgenerally be inferred simply by observing the device state. For example,simply because a vehicle is not running and has the keys in theignition, this does not imply that it is a good time for the vehicle tobe updated. The vehicle could be at a gas pump, weighing station, amongother scenarios, where the disabling of the vehicle for a time period toperform an update may be inappropriate.

Therefore, in accordance with the embodiments of the present disclosure,a user is allowed to initiate, via an electronic device, the update of anetwork connected device.

Further, in accordance with some embodiments of the present disclosure,a user may have difficulty identifying a specific device on which theupdate is to be performed. In such situation, a check that theappropriate device is being updated may be beneficial.

For example, when dealing with a fleet of vehicles such as trucks orrental vehicles, the person performing the update may have variousvehicles to select from. Utilizing a vehicle identification number orother similar unique identifier, identification of the particularvehicle that the user wishes to update may occur. However, such systemof selecting the vehicle may be error-prone and therefore, in accordancewith embodiments described below, checks may be made to ensure that thecorrect vehicle is being updated.

Further, as described below, a network connected device may be on adifferent network than the electronic device being used for the update.For example, a network connected device may be secured on a privatenetwork. Many cellular carriers configure their networks utilizingprivate networks.

However, the electronic device may be on a different private network.

Given that there is no guarantee that the device and the electronicdevice are on the same private network, direct connectivity between theelectronic device and the device being updated may be difficult.

Based on this, in accordance with the present disclosure, anintermediary server is provided, referred to herein as an over-the-air(OTA) switchboard. This server component is hosted in a manner thatmakes it available from the public internet and therefore both thedevice being updated and the electronic device can connect to suchserver.

In particular, reference is now made to FIG. 1 , which shows asimplified architecture for a system in accordance with the presentdisclosure. In the embodiment of FIG. 1 , a plurality of devices, namelydevices 110, 112 and 114, communicate through a base station 122 oraccess point 124 to the Internet 130 or other similar network. Asprovided above, devices 110, 112, or 114 may be any device that needs tohave software updates, and may, for example, be an ECU in a vehicle.

Communication may be with one or a plurality of the servers, such asservers 132 or 134 in the embodiment of FIG. 1 . For example, server 132may be an authentication server while server 134 may be an over-the-airswitchboard server in one embodiment. However, in other embodiments, thefunctionality of servers 132 and 134 may be found on a single server.

An electronic device 140 communicates through a base station 142 oraccess point 144 with Internet 130, and may thereby communicate withservers 132 and 134.

As indicated above, the electronic device 140 and a network device suchas device 110 may be on different private networks. For example, in theembodiment of FIG. 1 , electronic device 140 is in a first privatenetwork 146 with a carrier and device 110 may be in a second privatenetwork 126, with the same or a different carrier.

Based on potentially being on different private networks, communicationmay occur between an electronic device 140 and a device 110 utilizing aserver 132, as described in more detail below.

Utilizing a system as described with regard to FIG. 1 above, an updatemay occur based on a user receiving on an electronic device anotification that the vehicle or similar device to be updated has anupdate pending. Such update notification may be provided, for example,from an update server or other network element.

Specifically, reference is now made to FIG. 2 . In the embodiment ofFIG. 2 , an electronic device 210 may include software or an applicationfor initiating and monitoring updates on a vehicle.

An authentication service 212 provides authentication for both theelectronic device 210 as well as for vehicle communications, asdescribed below.

Further, a switchboard 214 allows communication between the electronicdevice 210 and a vehicle.

The vehicle 216 includes internal communications between components orElectronic Control Units (ECU). Such internal communications may bebased on any wired or wireless technology. The internal communicationsmay allow for firmware or software for a component in the vehicle to beupdated. In the example of FIG. 2 , the internal communication isperformed using CANBUS 217.

Further, vehicle 216 includes an over-the-air (OTA) client 218. The OTAclient 218 provides for communication between the vehicle 216 and theswitchboard 214.

In accordance with the embodiment of FIG. 2 , a software update may bedownloaded to a vehicle prior to the installation of such update. Theupdate may be provided, for example, through switchboard 214 or directlyfrom an update server (not shown). Such software update download isshown by block 220.

The download is however not installed at this point. The use of thepre-downloading of the update software allows installation of thesoftware to occur more quickly once installation is started.Pre-downloading also ensures that a disruption in network communicationswill not impact installation times.

However, in other embodiments, the installation of the software mayinclude downloading updates concurrently.

In the embodiment of FIG. 2 , if the software update is pre-downloaded,then the OTA client 218 may send a download complete message 222 to theswitchboard 214.

Switchboard 214 may then provide a download complete message 224directly to an electronic device 210 in some embodiments. In otherembodiments, the indication that the download is compete may be providedto a server such as to the authentication service 212 to provide anotification to the electronic device 210.

For example, in the embodiment of FIG. 2 , the authentication service212 may be used to provide a notification to the electronic device 210.In this regard, the authentication service may keep a list of electronicdevices associated with the vehicle from which message 222 was sent, asrelayed in message 224. However, this is not limiting and in otherembodiments, different servers may be used to associated electronicdevices to vehicles and send message 224.

In alternative embodiments in which pre-downloading does not occur, if aserver has received an indication that an update is available, theserver may keep a list or database of components installed in thevarious vehicles under its control. Therefore, the server may crossreference the update to a list of vehicles that need such update andthen may further cross-reference to electronic devices associated withthose vehicles.

Based on the association of the electronic device to the vehicle, the aserver such as authentication service 212 may then send a message to theassociated electronic device or devices, as shown with arrow 230 in theembodiment of FIG. 2 .

One of such subscribed users may be the user of electronic device 210.

At some subsequent time when the installation of the update isappropriate, the user may then log in to a phone application or othersoftware on electronic device 210 to initiate the installation of suchsoftware. In particular, in the embodiment of FIG. 2 , the user mayperform an authentication with the authentication service 212. A sessionidentifier may be provided based on the authentication. Theauthentication is shown with arrow 240 in the embodiment of FIG. 2 .

Once a user of the electronic device is authenticated with theauthentication service 212, an identifier for the vehicle or devicebeing upgraded may be entered. The identifier may be any number, code ordesignation that uniquely identifies the object being upgraded.

The identifier may be provided to the electronic device in various ways.For example, for a vehicle, the identification may be provided bymanually entering a vehicle identification number, or by scanning abarcode or QR code in the vehicle.

In other embodiments, the identifier may be provided by clicking on alink in the message or notification received at arrow 230. For example,an Android intent can be used to define a link in an email that couldthen launch an application on an Android type system. Similarfunctionality could be performed on an iOS device or other operatingsystem device.

In other embodiments, the identifier may be input utilizing a pre-storedlist within the electronic device 210. For example, a user may bepresented with a list of vehicle identifiers for vehicles associatedwith the electronic device 210, and a user may select an identifier fromthe list.

Other options for entering an identifier into electronic device 210 arepossible, and the present disclosure is not limited to any method ofproviding the identifier to the electronic device.

The entering of the identifier is shown in the embodiment of FIG. 2 witharrow 242.

Subsequently, the electronic device 210 connects and communicates withswitchboard 214 by sending a connect message 246. Connect message 246may include various information. For example, in the embodiment of FIG.2 the message includes the identifier entered at arrow 242, sessioninformation obtained at arrow 240, as well as user information. However,in other embodiments different information may be provided in theconnect message 246.

The switchboard 214 may then validate the session received in message246 with authentication service 212, as shown by arrow 248.

As will be appreciated by those in the art, the authentication servicemay be part of the switchboard 214, in which case, the validation atarrow 248 is internal. In this case, the session token may not berequired to be sent from the electronic device.

Once the electronic device is connected to the switchboard 214, theelectronic device may be prompted to have the user perform certainactions. For example, in the embodiment of FIG. 2 , the electronicdevice may prompt a user to put the vehicle into an update state asshown by arrow 250. This may involve turning the engine off but havingthe key in a standby position, among other options. The presentdisclosure is not limited to any particular actions that need to betaken to put the vehicle into an update state.

The application or software on the electronic device may then prompt auser to perform an action which would not normally occur while thevehicle is in such update state. For example, in the embodiment of FIG.2 , the prompt may involve instructing a user to press and hold a buttonor combination of buttons available to a user on the vehicle. This shownwith arrow 252 in the embodiment of FIG. 2 .

In particular, the combination of actions at arrows 250 and 252 wouldtypically not occur in the normal operation of the vehicle, therebycausing the vehicle to recognize that an update attempt is occurring.Specifically, in the embodiment of FIG. 2 , the CANBUS 217 on thevehicle realizes that the update state has been entered and that thebutton or combinations of buttons is being pressed. Therefore, theCANBUS 217 sends message 260 to the OTA client 218 indicating that theupdate preconditions have been met.

The OTA client 218 may then connect to the switchboard 214 by sending aconnect message 264 along with the identification number for thevehicle.

The switchboard 214 may provide a notification, as shown by message 268,to the electronic device 210 that a connection with the vehicle has beenestablished.

Further, the OTA client 218 may inform the switchboard 214 that theupdate preconditions have been met, as shown by arrow 270. This mayfurther be relayed by switchboard 214 to the electronic device 210, asshown with arrow 272.

The electronic device 210 may then enable a user interface to allow theupdates to be started, as shown by arrow 280. For example, a “start”button may be enabled or become visible on the electronic device toallow the user to start the update.

If the user interface receives an input, such as pressing of a startbutton or other similar action to start the update, then the electronicdevice 210 may send a start command to switchboard 214, shown by message282, which may then be relayed to the OTA client 218, shown by message284.

Subsequently, the OTA client 218 cause the update to be started and mayprovide periodic status updates on the installation process to theswitchboard 214, shown with arrow 290. Such status updates and progressreports may be relayed to the electronic device 210, as shown by arrow292.

For example, during the update process, the OTA client 218 sendsprogress information including items such as percentage completed andremaining, as well as the overall outcome of the installation process,to the switchboard. The switchboard may then forward this information tothe connected phone application or other element of the electronicdevice 210 to provide the user of the electronic device with suchinformation.

In this way, the user of such electronic device will know the status ofthe update and when the update finishes.

Utilizing the embodiment of FIG. 2 above, various functionality isachieved. In particular, if the user is managing a fleet of devices,there is a need to ensure that the device identifier entered into theelectronic device corresponds with the correct device to be updated.This is achieved based on the actions that are taken within the vehicleor other device being updated, along with interaction with theelectronic device. The concurrent physical action on the device beingupdated and action on the electronic device ensures that the correctdevice is updated.

Further, the above embodiments prevent unintended updates. For example,if the electronic device initiates an update but no message is receivedfrom the vehicle, then the update process will not be started and theenablement of the “start” button will not occur. Further, if the vehicleindicates that the conditions for an update have been met but noelectronic device has connected to try to do the update, then theswitchboard may assume that such update preconditions were enteredaccidentally and no update is initiated.

In some embodiments, once the update process starts, it will proceedthrough to completion. This completion is either a successful completionor based on a roll back or failure of the software update. This ensuresthat even if the connection is lost to either the vehicle or theelectronic device, that the update will continue.

In the above, security is provided through the fact that both the userof the electronic device needs to be authenticated to the authenticationservice, as well as the physical interaction with the device beingupdated. Thus, the combination of preconditions indicates that maliciousupdating of the vehicle is unlikely to occur. Further, the loading ofthe update itself may be done through a secure mechanism between thevehicle and an updated server.

With regard to the OTA switchboard 214, the switchboard may hold a listof vehicles and associated devices, and may simply forward messages fromone to the other utilizing any messaging format. Thus, once theassociation between the device and the vehicle is established, over theOTA switchboard 214 merely acts as a conduit for forwarding messagesbetween the two. For example, reference is now made to FIG. 3 , whichshows an association between the vehicle identification number data fora vehicle with a session owner user information from an electronicdevice.

In the embodiment of FIG. 3 , the VIN data 310 may be associated with aplurality of states or variables, including an update state, the currentsession owner, the vehicle operational state, the update progress, thecurrent release version, the current release install timestamp, and arelease initiator.

The session owner user information 320 contains information identifyinga user interacting with the remote OTA update control mechanism. Forexample, this may be an application on electronic device 210 from theembodiment of FIG. 2 .

The vehicle update preconditions 330 may be a set of preconditions thatare configured to indicate whether the vehicle is ready for updating.These conditions may involve, for example, putting the ignition key intoa run position without turning on the engine and holding cruise control.Other options including setting the parking brake, among other options,for the vehicle update preconditions are however possible.

Based on FIGS. 1 to 3 , a vehicle that does not have a feedbackmechanism can be updated through the use of an electronic device such asa mobile phone and through the use of a server that may act as aswitchboard for communications between the vehicle and the electronicdevice.

The device being updated or the electronic device may be any computingdevice. One simplified block diagram of a computing device is shown withregard to FIG. 4 .

In FIG. 4 , computing device 410 includes a processor 420 and acommunications subsystem 430, where the processor 420 and communicationssubsystem 430 cooperate to perform the methods of the embodimentsdescribed above. Communications subsystem 420 may, in some embodiments,comprise multiple subsystems, for example for different radiotechnologies.

Processor 420 is configured to execute programmable logic, which may bestored, along with data, on device 410, and shown in the example of FIG.4 as memory 440. Memory 440 can be any tangible, non-transitory computerreadable storage medium. The computer readable storage medium may be atangible or in transitory/non-transitory medium such as optical (e.g.,CD, DVD, etc.), magnetic (e.g., tape), flash drive, hard drive, or othermemory known in the art.

Alternatively, or in addition to memory 440, computing device 410 mayaccess data or programmable logic from an external storage medium, forexample through communications subsystem 430.

Communications subsystem 430 allows device 410 to communicate with otherdevices or network elements and may vary based on the type ofcommunication being performed. For example, if computing device 410 isan ECU, communications subsystem 430 may be the interface to a CANBUS.If computing device 410 is a server or OTA client then communicationssubsystem 430 may include wired or wireless communications such ascellular, WiFi, ethernet, fiber, among other options. Further,communications subsystem 430 may comprise a plurality of communicationstechnologies, including any wired or wireless communications technology.

Communications between the various elements of device 410 may be throughan internal bus 460 in one embodiment. However, other forms ofcommunication are possible.

The computing device of FIG. 4 could be any fixed or mobile device. Ifthe computing device is a mobile device, one example mobile device isdescribed below with regard to FIG. 5 .

Mobile device 500 may comprise a two-way wireless communication devicehaving voice or data communication capabilities or both. Mobile device500 generally has the capability to communicate with other computersystems. Depending on the exact functionality provided, the mobiledevice may be referred to as a data messaging device, a two-way pager, awireless e-mail device, a smartphone, a cellular telephone with datamessaging capabilities, a wireless Internet appliance, a wirelessdevice, a mobile device, an embedded cellular modem, an electronicdevice or a data communication device, as examples.

Where mobile device 500 is enabled for two-way communication, it mayincorporate a communication subsystem 511, including a receiver 512 anda transmitter 514, as well as associated components such as one or moreantenna elements 516 and 518, local oscillators (LOs) 513, and aprocessing module such as a digital signal processor (DSP) 520. As willbe apparent to those skilled in the field of communications, theparticular design of the communication subsystem 511 will be dependentupon the communication network in which the mobile device is intended tooperate.

Network access requirements will also vary depending upon the type ofnetwork 519. In some networks, network access is associated with asubscriber or user of the mobile device 500. A mobile device may requirean embedded or a removable user identity module (RUIM) or a subscriberidentity module (SIM) card or a UMTS SIM (USIM) in order to operate on anetwork. The USIM/SIM/RUIM interface 544 is normally similar to acard-slot into which a USIM/SIM/RUIM card can be inserted and ejected.The USIM/SIM/RUIM card can have memory and hold many key configurations551, and other information 553 such as identification, and subscriberrelated information.

When required network registration or activation procedures have beencompleted, mobile device 500 may send and receive communication signalsover the network 519. As illustrated in FIG. 5 , network 519 can includemultiple base stations communicating with the mobile device.

Signals received by antenna 516 through communication network 519 areinput to receiver 512, which may perform such common receiver functionsas signal amplification, frequency down conversion, filtering, channelselection and the like. Analog to digital (A/D) conversion of a receivedsignal allows more complex communication functions such as demodulationand decoding to be performed in the DSP 520. In a similar manner,signals to be transmitted are processed, including modulation andencoding for example, by DSP 520 and input to transmitter 514 fordigital to analog (D/A) conversion, frequency up conversion, filtering,amplification and transmission over the communication network 519 viaantenna 518. DSP 520 not only processes communication signals, but alsoprovides for receiver and transmitter control. For example, the gainsapplied to communication signals in receiver 512 and transmitter 514 maybe adaptively controlled through automatic gain control algorithmsimplemented in DSP 520.

Mobile device 500 generally includes a processor 538 which controls theoverall operation of the device. Communication functions, including dataand voice communications, are performed through communication subsystem511. Processor 538 also interacts with further device subsystems such asthe display 522, flash memory 524, random access memory (RAM) 526,auxiliary input/output (I/O) subsystems 528, serial port 530, one ormore keyboards or keypads 532, speaker 534, microphone 536, othercommunication subsystem 540 such as a short-range communicationssubsystem, DSRC subsystem 3GPP based V2X subsystem, or cellularsubsystem, and any other device subsystems generally designated as 542.Serial port 530 could include a USB port, On-Board Diagnostics (OBD)port or other port known to those in the art.

Some of the subsystems shown in FIG. 5 perform communication-relatedfunctions, whereas other subsystems may provide “resident” or on-devicefunctions. Notably, some subsystems, such as keyboard 532 and display522, for example, may be used for both communication-related functions,such as entering a text message for transmission over a communicationnetwork, and device-resident functions such as a calculator or tasklist.

Operating system software used by the processor 538 may be stored in apersistent store such as flash memory 524, which may instead be aread-only memory (ROM) or similar storage element (not shown). Thoseskilled in the art will appreciate that the operating system, specificdevice applications, or parts thereof, may be temporarily loaded into avolatile memory such as RAM 526. Received communication signals may alsobe stored in RAM 526.

As shown, flash memory 524 can be segregated into different areas forboth computer programs 558 and program data storage 550, 552, 554 and556. These different storage types indicate that each program canallocate a portion of flash memory 524 for their own data storagerequirements. Processor 538, in addition to its operating systemfunctions, may enable execution of software applications on the mobiledevice. A predetermined set of applications that control basicoperations, including potentially data and voice communicationapplications for example, will normally be installed on mobile device500 during manufacturing. Other applications could be installedsubsequently or dynamically.

Applications and software may be stored on any computer readable storagemedium. The computer readable storage medium may be a tangible or intransitory/non-transitory medium such as optical (e.g., CD, DVD, etc.),magnetic (e.g., tape) or other memory known in the art.

One software application may be a personal information manager (PIM)application having the ability to organize and manage data itemsrelating to the user of the mobile device such as, but not limited to,e-mail, messages, calendar events, voice mails, appointments, and taskitems. Further applications, including device update applications,productivity applications, social media applications, games, amongothers, may also be loaded onto the mobile device 500 through thenetwork 519, an auxiliary I/O subsystem 528, serial port 530,short-range communications subsystem 540 or any other suitable subsystem542, and installed by a user in the RAM 526 or a non-volatile store (notshown) for execution by the processor 538. Such flexibility inapplication installation increases the functionality of the device andmay provide enhanced on-device functions, communication-relatedfunctions, or both.

In a data communication mode, a received signal such as a text messageor web page download will be processed by the communication subsystem511 and input to the processor 538, which may further process thereceived signal for output to the display 522, or alternatively to anauxiliary I/O device 528.

A user of mobile device 500 may also compose data items such as messagesfor example, using the keyboard 532, which may be a completealphanumeric keyboard or telephone-type keypad, either physical orvirtual, among others, in conjunction with the display 522 and possiblyan auxiliary I/O device 528. Such composed items may then be transmittedover a communication network through the communication subsystem 511.

Where voice communications are provided, overall operation of mobiledevice 500 is similar, except that received signals may typically beoutput to a speaker 534 and signals for transmission may be generated bya microphone 536. Alternative voice or audio I/O subsystems, such as avoice message recording subsystem, may also be implemented on mobiledevice 500. Although voice or audio signal output is preferablyaccomplished primarily through the speaker 534, display 522 may also beused to provide an indication of the identity of a calling party, theduration of a voice call, or other voice call related information forexample.

Serial port 530 in FIG. 5 may be implemented in a mobile device forwhich synchronization with a user's desktop computer (not shown) may bedesirable, but is an optional device component. Such a port 530 mayenable a user to set preferences through an external device or softwareapplication and may extend the capabilities of mobile device 500 byproviding for information or software downloads to mobile device 500other than through a wireless communication network. As will beappreciated by those skilled in the art, serial port 530 can further beused to connect the mobile device to a computer to act as a modem or forcharging a battery on the mobile device.

Other communications subsystems 540, such as a short-rangecommunications subsystem, is a further component which may provide forcommunication between mobile device 500 and different systems ordevices, which need not necessarily be similar devices. For example, thesubsystem 540 may include an infrared device and associated circuits andcomponents or a Bluetooth™ or Bluetooth™ Low Energy communication moduleto provide for communication with similarly enabled systems and devices.Subsystem 540 may further include a DSRC radio or similar radio.Subsystem 540 may further include non-cellular communications such asWi-Fi or WiMAX, or near field communications.

The embodiments described herein are examples of structures, systems ormethods having elements corresponding to elements of the techniques ofthis application. This written description may enable those skilled inthe art to make and use embodiments having alternative elements thatlikewise correspond to the elements of the techniques of thisapplication. The intended scope of the techniques of this applicationthus includes other structures, systems or methods that do not differfrom the techniques of this application as described herein, and furtherincludes other structures, systems or methods with insubstantialdifferences from the techniques of this application as described herein.

While operations are depicted in the drawings in a particular order,this should not be understood as requiring that such operations beperformed in the particular order shown or in sequential order, or thatall illustrated operations be performed, to achieve desirable results.In certain circumstances, multitasking and parallel processing may beemployed. Moreover, the separation of various system components in theimplementation descried above should not be understood as requiring suchseparation in all implementations, and it should be understood that thedescribed program components and systems can generally be integratedtogether in a single software product or packaged into multiple softwareproducts.

Also, techniques, systems, subsystems, and methods described andillustrated in the various implementations as discrete or separate maybe combined or integrated with other systems, modules, techniques, ormethods. Other items shown or discussed as coupled or directly coupledor communicating with each other may be indirectly coupled orcommunicating through some interface, device, or intermediate component,whether electrically, mechanically, or otherwise. Other examples ofchanges, substitutions, and alterations are ascertainable by one skilledin the art and may be made.

While the above detailed description has shown, described, and pointedout the fundamental novel features of the disclosure as applied tovarious implementations, it will be understood that various omissions,substitutions, and changes in the form and details of the systemillustrated may be made by those skilled in the art. In addition, theorder of method steps are not implied by the order they appear in theclaims.

When messages are sent to/from an electronic device, such operations maynot be immediate or from the server directly. They may be synchronouslyor asynchronously delivered, from a server or other computing systeminfrastructure supporting the devices/methods/systems described herein.The foregoing steps may include, in whole or in part,synchronous/asynchronous communications to/from thedevice/infrastructure. Moreover, communication from the electronicdevice may be to one or more endpoints on a network. These endpoints maybe serviced by a server, a distributed computing system, a streamprocessor, etc. Content Delivery Networks (CDNs) may also provide mayprovide communication to an electronic device. For example, rather thana typical server response, the server may also provision or indicate adata for content delivery network (CDN) to await download by theelectronic device at a later time, such as a subsequent activity ofelectronic device. Thus, data may be sent directly from the server, orother infrastructure, such as a distributed infrastructure, or a CDN, aspart of or separate from the system.

Typically, storage mediums can include any or some combination of thefollowing: a semiconductor memory device such as a dynamic or staticrandom access memory (a DRAM or SRAM), an erasable and programmableread-only memory (EPROM), an electrically erasable and programmableread-only memory (EEPROM) and flash memory; a magnetic disk such as afixed, floppy and removable disk; another magnetic medium includingtape; an optical medium such as a compact disk (CD) or a digital videodisk (DVD); or another type of storage device. Note that theinstructions discussed above can be provided on one computer-readable ormachine-readable storage medium, or alternatively, can be provided onmultiple computer-readable or machine-readable storage media distributedin a large system having possibly a plurality of nodes. Suchcomputer-readable or machine-readable storage medium or media is (are)considered to be part of an article (or article of manufacture). Anarticle or article of manufacture can refer to any manufactured singlecomponent or multiple components. The storage medium or media can belocated either in the machine running the machine-readable instructions,or located at a remote site from which machine-readable instructions canbe downloaded over a network for execution.

In the foregoing description, numerous details are set forth to providean understanding of the subject disclosed herein. However,implementations may be practiced without some of these details. Otherimplementations may include modifications and variations from thedetails discussed above. It is intended that the appended claims coversuch modifications and variations.

1. A method at a device to be updated, the method comprising:determining, at the device to be updated, that the device to be updatedhas entered an update state; receiving, using a user interface at thedevice to be updated, a physical authentication interaction; based onthe determining and receiving, sending both a connection request andinformation that update conditions have been met to a switchboard;receiving, from the switchboard, instructions to start an update.
 2. Themethod of claim 1, wherein the connection request includes an identifierused by the switchboard to pair with a second device.
 3. The method ofclaim 2, wherein the identifier is a vehicle identification number. 4.The method of claim 1, wherein further comprising: starting the update;and sending, to the switchboard, status messages concerning the update.5. The method of claim 1, wherein the physical authenticationinteraction comprises a user input that would only occur to signal thatan update attempt is being requested.
 6. The method of claim 1, whereinthe physical authentication interaction provides verification to theswitchboard that a user is present at the device to be updated.
 7. Themethod of claim 1, wherein the device to be updated has no updatefeedback interface.
 8. The method of claim 1, wherein the device to beupdate is a vehicle, and wherein the update state comprises having keysin a standby position and wherein the physical authenticationinteraction comprises pushing a button within the vehicle.
 9. Acomputing device configured to be updated, the computing devicecomprising: a processor; and a communications subsystem, wherein thecomputing device is configured to: determine that the computing devicehas entered an update state; receive using a user interface at thecomputing device, a physical authentication interaction; based on thedetermining and receiving, sending both a connection request andinformation that update conditions have been met to a switchboard;receiving, from the switchboard, instructions to start an update. 10.The computing device of claim 9, wherein the connection request includesan identifier used by the switchboard to pair with a second device. 11.The computing device of claim 10, wherein the identifier is a vehicleidentification number.
 12. The computing device of claim 9, wherein thecomputing device is further configured to: start the update; and send,to the switchboard, status messages concerning the update.
 13. Thecomputing device of claim 9, wherein the physical authenticationinteraction comprises a user input that would only occur to signal thatan update attempt is being requested.
 14. The method of claim 9, whereinthe physical authentication interaction provides verification to theswitchboard that a user is present at the computing device.
 15. Thecomputing device of claim 9, wherein the computing device has no updatefeedback interface.
 16. The computing device of claim 9, wherein thecomputing device is a vehicle, and wherein the update state compriseshaving keys in a standby position and wherein the physicalauthentication interaction comprises pushing a button within thevehicle.
 17. A non-transitory computer readable medium for storinginstruction code, which when executed by a processor of a computingdevice cause the computing device to: determine that the computingdevice has entered an update state; receive using a user interface atthe computing device, a physical authentication interaction; based onthe determining and receiving, sending both a connection request andinformation that update conditions have been met to a switchboard;receiving, from the switchboard, instructions to start an update. 18.The non-transitory computer readable medium of claim 17, wherein thephysical authentication interaction provides verification to theswitchboard that a user is present at the computing device.
 19. Thenon-transitory computer readable medium of claim 17, wherein thecomputing device has no update feedback interface.
 20. Thenon-transitory computer readable medium of claim 17, wherein thecomputing device is a vehicle, and wherein the update state compriseshaving keys in a standby position and wherein the physicalauthentication interaction comprises pushing a button within thevehicle.